Skip to main content

第 6 章:Cloud Native 安全概論

Cloud native 4C

分層去考慮安全性,雲原生安全的 4 個 C 分別是雲(Cloud)、集群(Cluster)、容器(Container)和代碼(Code

雲原生安全模型的每一層都是基於下一個最外層,代碼層受益於強大的基礎安全層(雲、集群、容器)。 你無法通過在代碼層解決安全問題來為基礎層中糟糕的安全標準提供保護。

雲 Cloud

在許多方面,雲(或者位於同一位置的服務器,或者是公司數據中心)是 Kubernetes 集群中的可信計算基。 如果雲層容易受到攻擊(或者被配置成了易受攻擊的方式),就不能保證在此基礎之上構建的組件是安全的。 每個雲提供商都會提出安全建議,以在其環境中安全地運行工作負載。

基礎設施安全

關於在 Kubernetes 集群中保護你的基礎設施的建議

Kubernetes 基礎架構關注領域建議
通過網絡訪問 API 服務(控制平面)所有對 Kubernetes 控制平面的訪問不允許在 Internet 上公開,同時應由網絡訪問控制列表控制,該列表包含管理集群所需的 IP 地址集。
通過網絡訪問 Node(節點)節點應配置為 僅能 從控制平面上通過指定端口來接受(通過網絡訪問控制列表)連接,以及接受 NodePort 和 LoadBalancer 類型的 Kubernetes 服務連接。如果可能的話,這些節點不應完全暴露在公共互聯網上。
Kubernetes 訪問雲提供商的 API每個雲提供商都需要向 Kubernetes 控制平面和節點授予不同的權限集。為集群提供雲提供商訪問權限時,最好遵循對需要管理的資源的最小特權原則。Kops 文檔提供有關 IAM 策略和角色的信息。
訪問 etcd對 etcd(Kubernetes 的數據存儲)的訪問應僅限於控制平面。根據配置情況,你應該嘗試通過 TLS 來使用 etcd。更多信息可以在 etcd 文檔中找到。
etcd 加密在所有可能的情況下,最好對所有存儲進行靜態數據加密,並且由於 etcd 擁有整個集群的狀態(包括機密信息),因此其磁盤更應該進行靜態數據加密。

集群 Cluster

保護 Kubernetes 有兩個方面需要注意:

  • 保護可配置的集群組件
  • 保護在集群中運行的應用程序

集群組件

如果想要保護集群免受意外或惡意的訪問,采取良好的信息管理實踐,請閱讀並遵循有關保護集群的建議。

集群中的組件(你的應用)

根據你的應用程序的受攻擊面,你可能需要關注安全性的特定面,比如: 如果你正在運行中的一個服務(A 服務)在其他資源鏈中很重要,並且所運行的另一工作負載(服務 B) 容易受到資源枯竭的攻擊,則如果你不限制服務 B 的資源的話,損害服務 A 的風險就會很高。 下表列出了安全性關注的領域和建議,用以保護 Kubernetes 中運行的工作負載

工作負載安全性關注領域建議
RBAC 授權(訪問 Kubernetes API)https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/
認證方式https://kubernetes.io/zh-cn/docs/concepts/security/controlling-access/
應用程序 Secret 管理 (並在 etcd 中對其進行靜態數據加密)https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/encrypt-data/
確保 Pod 符合定義的 Pod 安全標準https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation
服務質量(和集群資源管理)https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/
網絡策略https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/
Kubernetes Ingress 的 TLS 支持https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#tls

容器 Container

容器安全性不在本指南的探討範圍內。下面是一些探索此主題的建議和連接

容器關注領域建議
容器漏洞掃描和操作系統依賴安全性作為鏡像構建的一部分,你應該掃描你的容器里的已知漏洞。
鏡像簽名和執行對容器鏡像進行簽名,以維護對容器內容的信任。
禁止特權用戶構建容器時,請查閱文檔以了解如何在具有最低操作系統特權級別的容器內部創建用戶,以實現容器的目標。
使用帶有較強隔離能力的容器運行時選擇提供較強隔離能力的容器運行時類。

代碼 Code

應用程序代碼是你最能夠控制的主要攻擊面之一,雖然保護應用程序代碼不在 Kubernetes 安全主題範圍內,但以下是保護應用程序代碼的建議:

代碼安全性

代碼關注領域建議
僅通過 TLS 訪問如果你的代碼需要通過 TCP 通信,請提前與客戶端執行 TLS 握手。除少數情況外,請加密傳輸中的所有內容。更進一步,加密服務之間的網絡流量是一個好主意。這可以通過被稱為雙向 TLS 或 mTLS 的過程來完成,該過程對兩個證書持有服務之間的通信執行雙向驗證。
限制通信端口範圍此建議可能有點不言自明,但是在任何可能的情況下,你都只應公開服務上對於通信或度量收集絕對必要的端口。
第三方依賴性安全最好定期掃描應用程序的第三方庫以了解已知的安全漏洞。每種編程語言都有一個自動執行此檢查的工具。
靜態代碼分析大多數語言都提供給了一種方法,來分析代碼段中是否存在潛在的不安全的編碼實踐。只要有可能,你都應該使用自動工具執行檢查,該工具可以掃描代碼庫以查找常見的安全錯誤,一些工具可以在以下連接中找到: https://owasp.org/www-community/Source_Code_Analysis_Tools
動態探測攻擊你可以對服務運行一些自動化工具,來嘗試一些眾所周知的服務攻擊。這些攻擊包括 SQL 注入、CSRF 和 XSS。OWASP Zed Attack 代理工具是最受歡迎的動態分析工具之一。